I've added strict types declaration to the new (test) source file.

@sabberworm, can you give this a quick look to confirm you think it's OK for now.

Longer term, I think it would be cleaner to introduce a Value\Expression class to encapsulate arithmetic. For now, this change allows construction from parsing of a RuleValueList with components like {0: Size, 1: string, 2: Size} where the string is the operator. Longer term we'd want to support nested expressions with brackets, and direct expressions as values (both of which I think CSS4 allows, the latter with syntax like width: (100px + 10%), i.e. omission of the calc keyword, though can't offhand find a reference).

There is calling for a release with this in ASAP, at least as far as CSS3, hence I think this interim solution will suffice, as full CSS4 support may take some time and effort.

Ah, no, stop the press: We still need a changelog entry for this new feature.

Indeed we do. It's lack was a deliberate alertness test ;)

Also corrected nomenclature of the numeric part of a length value (MDN calls it a 'number' not a 'value').

I've updated this again. I noted that arithmetic in calc already worked, so the test I had for calc(A + B + C) was already passing. So I've extended that test to also include max(X, A + B + C) (which would previously fail).

Longer term, I think it would be cleaner to introduce a Value\Expression class to encapsulate arithmetic

Just re-spotted that #389 seeks to do just that. Though it is a PR on top of a PR, so may be somewhat awkward to unravel.

Longer term, I think it would be cleaner to introduce a Value\Expression class to encapsulate arithmetic.

Yes, absolutely. I'd also like to check our class naming and structure against the terms and concepts used in the the official specification.

I'd also like to check our class naming and structure against the terms and concepts used in the the official specification.

I'm finding a very close if not exact match there. Kudos to @sabberworm. But, yes, please do review.

Just re-spotted that #389 seeks to do just that. Though it is a PR on top of a PR, so may be somewhat awkward to unravel.

Looking at that, the new Expression class doesn't seem to be connected to anything, so it seems a WIP. Although I had briefly looked at it before, I had forgotten. So I would consider it two people independently coming up with the same idea...

Yes, absolutely. I'd also like to check our class naming and structure against the terms and concepts used in the the official specification.

… but not as part of this PR. :-)